Virtual network verification service

ABSTRACT

A virtual network verification service for provider networks that leverages a declarative logic programming language to allow clients to pose queries about their virtual networks as constraint problems; the queries may be resolved using a constraint solver engine. Semantics and logic for networking primitives of virtual networks in the provider network environment may be encoded as a set of rules according to the logic programming language; networking security standards and/or client-defined rules may also be encoded in the rules. A description of a virtual network may be obtained and encoded. A constraint problem expressed by a query may then be resolved for the encoded description according to the encoded rules using the constraint solver engine; the results may be provided to the client.

BACKGROUND

Many companies and other organizations operate computer networks thatinterconnect numerous computing systems to support their operations,such as with the computing systems being co-located (e.g., as part of alocal network) or instead located in multiple distinct geographicallocations (e.g., connected via one or more private or publicintermediate networks). For example, data centers housing significantnumbers of interconnected computing systems have become commonplace,such as private data centers that are operated by and on behalf of asingle organization, and public data centers that are operated byentities as businesses to provide computing resources to customers. Somepublic data center operators provide network access, power, and secureinstallation facilities for hardware owned by various customers, whileother public data center operators provide “full service” facilitiesthat also include hardware resources made available for use by theircustomers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a virtual network verification service in a providernetwork environment, according to some embodiments.

FIG. 2 illustrates components and operation of an example virtualnetwork verification service, according to some embodiments.

FIG. 3 illustrates a client providing descriptive information for avirtual network and queries to a virtual network verification servicethat processes the query and provides results to the client, accordingto some embodiments.

FIG. 4 illustrates a client providing queries and permission to access avirtual network to a virtual network verification service that obtainsdescriptive information from the virtual network, processes the query,and provides results to the client, according to some embodiments.

FIG. 5 is a high-level flowchart of a method for providing informationabout a virtual network to clients of a provider network, according tosome embodiments.

FIG. 6 is a flowchart of a method for providing information about avirtual network to clients of a provider network in which the clientprovides descriptive information and queries to a virtual networkverification service, according to some embodiments.

FIG. 7 is a flowchart of a method for providing information about avirtual network to clients of a provider network in which the clientprovides descriptive information and permissions to access a virtualnetwork to a virtual network verification service, according to someembodiments.

FIG. 8 illustrates a virtual network implementation in a providernetwork environment that includes peered virtual networks, according tosome embodiments.

FIG. 9 is a flowchart of a method for automatically synthesizing virtualnetworks for clients, according to some embodiments.

FIG. 10 is a flowchart of another method for automatically synthesizingvirtual networks for clients, according to some embodiments.

FIG. 11 illustrates an example provider network environment, accordingto some embodiments.

FIG. 12 illustrates an example data center that implements an overlaynetwork on a network substrate using IP tunneling technology, accordingto some embodiments.

FIG. 13 is a block diagram of an example provider network that providesa storage virtualization service and a hardware virtualization serviceto clients, according to some embodiments.

FIG. 14 illustrates an example provider network that provides virtualnetworks to at least some clients, according to some embodiments.

FIG. 15 illustrates subnets and security groups in an example virtualnetwork on a provider network, according to some embodiments.

FIG. 16 is a block diagram illustrating an example computer system thatmay be used in some embodiments.

While embodiments are described herein by way of example for severalembodiments and illustrative drawings, those skilled in the art willrecognize that embodiments are not limited to the embodiments ordrawings described. It should be understood, that the drawings anddetailed description thereto are not intended to limit embodiments tothe particular form disclosed, but on the contrary, the intention is tocover all modifications, equivalents and alternatives falling within thespirit and scope as defined by the appended claims. The headings usedherein are for organizational purposes only and are not meant to be usedto limit the scope of the description or the claims. As used throughoutthis application, the word “may” is used in a permissive sense (i.e.,meaning having the potential to), rather than the mandatory sense (i.e.,meaning must). Similarly, the words “include”, “including”, and“includes” mean including, but not limited to. When used in the claims,the term “or” is used as an inclusive or and not as an exclusive or. Forexample, the phrase “at least one of x, y, or z” means any one of x, y,and z, as well as any combination thereof.

DETAILED DESCRIPTION

Various embodiments of methods and apparatus for verifying virtualnetworks in provider network environments are described. Embodiments ofa virtual network verification service are described that leverage adeclarative logic programming language to allow clients to expressqueries, including recursive queries, about their virtual networks onprovider networks as constraint problems, and provide results for thequeries by resolving the queries using a constraint solver (e.g., asatisfiability modulo theories (SMT) solver) engine. An exampledeclarative logic programming language that may be used in someembodiments is Datalog. Note that other declarative logic programminglanguages may be used.

Various provider network services may be used by clients to provisionand configure networking primitives in their virtual networks; eachservice may provide its own application programming interfaces (APIs)and networking semantics. Conventionally, while code samples anddocumentation may be provided for each service, there has been no formaldescription of the interactions between the networking primitives invirtual networks. In embodiments, virtual networking semantics and logicfor the networking primitives may be expressed and encoded as a set ofvirtual networking rules according to the logic programming language.The virtual networking rules may include rules that express commonrelationships and interactions among the various networking primitivesthat may be implemented in virtual networks and that are provided by theprovider network's services and APIs. Thus, embodiments may provide, inone location or file, virtual networking rules that describe the logicof how virtual networking works in the provider network environment.

In some embodiments, the virtual networking rules may incorporate rulesthat encode networking security standards such as the Payment CardIndustry Data Security Standard (PCI DSS), the Federal Risk andAuthorization Management Program (FedRAMP) standard, or the HealthInsurance Portability and Accountability Act (HIPPA) standard, or aclient's internal security standards. In some embodiments, the virtualnetwork verification service may provide two or more different sets ofvirtual networking rules that each encode different networking securitystandards that may be selectively used by clients to verify that theirvirtual networks conform to particular standards. In some embodiments,the virtual network verification service may allow a client to definecustom rules that encode the client's internal security standards, bestpractices, or other networking requirements, and thus sets of virtualnetworking rules may be implemented that include custom rules defined bythe clients for application to their particular virtual networks.

In embodiments, the virtual network verification service obtainsdescriptive information for a client's virtual network. The descriptiveinformation may, for example, identify instances of the networkingprimitives that are implemented in the virtual network, includedescriptions of the instances (e.g., roles assigned to computationinstances, permissions granted to or denied to resource instances, IPaddresses assigned to the instances, etc.), describe relationships amongthe instances (e.g., paths over the network between instances), anddescribe interfaces or access points to external entities (e.g.,computation instances that can be accessed by entities external to thevirtual network). In some embodiments, the client may obtain thedescriptive information from the virtual network and provide thedescriptive information to the virtual network verification service.Alternatively, in some embodiments, the client may grant permission tothe virtual network verification service to allow the virtual networkverification service to obtain the descriptive information directly fromthe virtual network. The virtual network verification service may encodethe descriptive information as logic programs according to thedeclarative logic programming language.

Embodiments of the virtual network verification service may providesignificant advantages when compared to conventional network analysismethods such as port scanning and syntactic check methods. Unlike theseconventional methods, through the encoded virtual networking rules andvirtual network description, the virtual network verification servicehas knowledge of all networking primitives and resource instances aswell as their complex interrelationships. Unlike conventional methodsthat rely on devices being up at the time of the scan, and that thus mayonly identify paths over the network between devices that exist at thetime of the scan, the descriptive information may be obtained by theclient or by the service using only DESCRIBE calls to APIs of one ormore provider network services that maintain metadata describing virtualnetworks, and thus paths over the network can be identified even ifrespective devices or instances are not up and listening. Further, portscanning methods may identify the existence of threats, but not theabsence of threats. Syntactic check methods may check shallow propertiesof individual network devices, but do not identify the presence orabsence of attack vectors. Embodiments of the virtual networkverification service, on the other hand, may find all possibledeviations from network policies as expressed in the encoded virtualnetworking rules, and may identify both the presence and the absence ofthreats and attack vectors. In addition, the descriptive information maybe obtained by the client or by the service using only DESCRIBE calls toone or more provider network services that maintain metadata describingvirtual networks, and thus unlike conventional methods such as portscanning methods that require substantial network and CPU bandwidththere is little or no impact on the client's virtual network, andfurther complete network access to every device on the provider networkis not required as is the case with port scanning methods.

In embodiments, the virtual network verification service receivesqueries from the client. In some embodiments, the queries may be posedin an expressive query language that is similar to SQL, but that appliesto network configurations. A non-limiting example of such a query may besomething like “VNVS query-i list: can-ssh(A,B)” that requests thevirtual network verification service (VNVS) to provide a list of allpairs of instances such that instance A can SSH to instance B.Alternatively, in some embodiments, the queries may be posed inhuman-friendly ways. A non-limiting example of such a query may besomething like “Show me a list of all pairs of instances, such that aninstance A can SSH into an instance B.” In some embodiments, at leastsome queries may be pre-defined and provided to the client in userinterface elements (e.g., menus) via a graphical interface to thevirtual network verification service.

The queries correspond to theorems about the generated logic programsand express constraint problems. The virtual network verificationservice resolves the constraint problems expressed by the queries forthe encoded description according to the encoded rules using aconstraint solver program (also referred to as a constraint solverengine) configured to resolve constraint problems according to thedeclarative logic programming language, and provides the results to theclient. In some embodiments, the virtual network verification servicemay provide an API and interface for posing queries. In someembodiments, the virtual network verification service may provide a setof standard queries that the client can select via the API andinterface. In some embodiments, the virtual network verification servicemay allow the client to compose and submit custom queries via the APIand interface.

In embodiments, the virtual network verification service may be used bya client, via a graphical interface to the service on a console or via acommand line interface (CLI), to obtain answers to questions (posed asqueries that specify constraints) about their virtual network on theprovider network. Example questions that may be posed as queriesinclude, but are not limited to:

-   -   Which instances in the virtual network are accessible from the        Internet?    -   Which instances can access specified resources on the virtual        network (e.g., a database, a cache, a storage endpoint, another        instance, etc.)?    -   Does the virtual network conform to best practices of a        networking security standard?    -   Does the virtual network comply with my company's best practices        as encoded in this set of rules?

More generally, the virtual network verification service may be used bya client to verify that expected pipes between resources in the virtualnetwork and other resources in the virtual network, as well as expectedpipes to external entities, are open, and that the expected pipes arethe only open pipes (e.g., that external entities cannot reach resourcesin the virtual network which they should not be allowed to reach).

Verifying that a pipebetween a resource and other resources in thevirtual network or a pipe between a resource in the virtual network andexternal entities is open may include verifying that there is a path orroute over the network (i.e., that there is network connectivity)between the resources or between a resource and the external entities(e.g., a path from the resource to an HTTPS gateway via which externalentities may access resources on the virtual network). A path may be adirect path over the network that provides network connectivity betweenendpoints, or alternatively may be a transitive path that passes throughone or more hops on a route and that provides network connectivitybetween endpoints. Descriptive information for the virtual network maybe obtained using only DESCRIBE calls to APIs of one or more providernetwork services that maintain metadata describing virtual networks, andthus paths may be verified even if respective devices or instances arenot up and listening. In some embodiments, the descriptive informationfor the virtual network may include permissions granted or denied toresources (e.g., a permission granting or denying one resource access toan endpoint on the virtual network, permissions specifying IP addressranges or particular ports of resource instances that can or cannotaccess a given endpoint (e.g., a storage endpoint), etc.). In theseembodiments, verifying that a path in the virtual network is open mayinclude verifying that the required permissions for the path have beengranted. Similarly, verifying that expected paths are the only openpaths may include determining that resources in the virtual network orexternal entities do not have permission to access resources that theyshould not have access to.

Embodiments of the virtual network verification service with appropriatesets of virtual networking rules may, for example, be used by clients tohelp the customers verify that their virtual networks comply withnetworking security standards such as the Payment Card Industry DataSecurity Standard (PCI DSS), the Federal Risk and AuthorizationManagement Program (FedRAMP) standard, or the Health InsurancePortability and Accountability Act (HIPPA) standard, or to verify thattheir virtual networks comply with the client's internal securitystandards or other internal networking requirements.

Another example application for embodiments of the virtual networkverification service is for identifying possible impact in the virtualnetwork of vulnerabilities such as network security issues or softwarebugs. For example, if a vulnerability is discovered in a particularsoftware program running on a particular instance in the virtualnetwork, the client may compose and submit queries to determine all theways that this instance can communicate with other instances in thevirtual network. The results may allow the client to identify thepossible impact of the vulnerability, and thus to make a decision as tohow to best handle the situation. For example, if there is no directpath from the instance with the vulnerability to an instance with amission-critical database, the problem may be given a lower priority tobe handled according to a normal maintenance schedule. If the instancewith the vulnerability will impact the instance with themission-critical database, the decision may be made to shut down atleast part of the virtual network to address the vulnerabilityimmediately.

Another example application for embodiments of the virtual networkverification service is in offline testing of changes to virtualnetworking for the provider network environment. For example, thevirtual networking rules that describe the logic of how virtualnetworking works in the provider network environment can be used in atesting environment to test changes to the virtual networking primitivesbefore the changes are applied to the provider network to determine whateffects the changes may have on virtual networks.

Another example application for embodiments of the virtual networkverification service is in automatically synthesizing virtual networksfor clients. For example, a client may want to establish a virtualnetwork that complies with a particular networking security standard andthat contains a specified set of networking primitives. The virtualnetwork verification service and virtual networking rules can be used inautomatically synthesizing and verifying a virtual network thatsatisfies all of the constraints (client-specified primitives,networking security standard, virtual networking rules that describe thelogic of how virtual networking works in the provider networkenvironment, etc.) so that the client does not have to build and testthe virtual network themselves. For example, constraints imposed by thestandards can be posed as queries, and the queries can be resolved todetermine a virtual network configuration that satisfies theconstraints, or alternatively to determine if the configuration of avirtual network conforms to the constraints. A virtual network thatconforms to the constraints may then be synthesized, or alternatively avirtual network may be modified to conform to the constraints.

Another example application for embodiments of the virtual networkverification service is in allowing a client to verify new virtualnetwork configurations or changes to existing virtual networks beforethe configurations or changes are implemented on the provider network.For example, a virtual network configuration may be generated ormodified by the client, and constraints for the configuration can beposed as queries; the queries may be resolved to verify that theconfiguration conforms to the client's constraints as posed in thequeries before the configuration is implemented on the provider network.

FIG. 1 illustrates a virtual network verification service in a providernetwork environment, according to some embodiments. A service providerthat provides a provider network 100 for clients may provide servicesand application programming interfaces (APIs) 102 that allow clients toestablish and manage resources in virtual networks 110 on the providernetwork 100. A virtual network 110 in a provider network 100 environmentmay be broadly defined as a network space (e.g., logically defined by anaddress range or address space) that contains a set of provider networkresources of a respective client, and that acts as a logically isolatedsection on the provider network 100 for the client's resources. Avirtual network 110 may implement a private or local Internet Protocol(IP) address space according to a network protocol, for example 32-bitIP addresses within an Internet Protocol version 4 (IPv4) address rangeor subnet. Sources (e.g., endpoints such as computation resources,storage resources, servers, host devices, etc.) on a virtual network 110may be assigned IP addresses (e.g., 32-bit IPv4 addresses) within thevirtual network 110's address space. A client's virtual network 110 onthe provider network 100 includes the client's resource instances, suchas virtual machines (VMs) on host devices configured as virtualcomputing resource instances by the client. At least some of theresource instances on a provider network may be implemented according tohardware virtualization technology that enables multiple operatingsystems to run concurrently on a host computer, i.e. as VMs on a hostdevice. A hypervisor, or virtual machine monitor (VMM), on the hostdevice presents the VMs on the respective host with a virtual platformand monitors the execution of the VMs on the host device. Each VM may beprovided with one or more IP addresses; the VMM on a respective host maybe aware of the IP addresses of the VMs on the host.

Various networking resources, structures, and functionalities (referredto as networking primitives) may be provided to clients of the providernetwork 100 via the various provider network services 102. Clients maycreate, configure, populate, and modify their virtual networks 110 onthe provider network 100 at least in part using the various services andAPIs 102. The following lists example networking primitives that may beprovided by the services 102, and is not intended to be limiting:

-   -   Virtual networks, for example as illustrated in FIGS. 1, 14, and        15.    -   Resource instances (e.g., VMs configured as virtual computing        resource instances (e.g., application servers, web servers,        database servers, access points, gateways, load balancers,        instances of particular provider network services such as        logging services, network monitoring and analysis services, code        repository services, container management services, etc.) by the        client using the services 102).    -   Tags—In some embodiments, a client may be allowed to assign        particular roles to particular resource instances (e.g., VMs)        within their virtual network(s) by tagging the resource        instances. A tag may, for example, be a text string such as PROD        or DEV. The tags may be stored in metadata for the resource        instances. The tags may include standard provider        network-defined tags and/or client-defined tags. Example roles        for resource instances include, but are not limited to, Secure        Socket Shell (SSH) access instances, logging service instances,        code repository instances, production resource instances, and        development resource instances.    -   Virtual network endpoints (e.g., endpoints such as computation        resources, storage resources, servers, host devices, etc.).    -   Virtual network peering connections. In some embodiments, a        client may establish two or more virtual networks on a provider        network. A peering connection may be established between the        virtual networks that allows the virtual networks to securely        communicate over the provider network without having to traverse        an external network such as the Internet.    -   Internet gateways that provide access to at least some of a        virtual network's resources from entities external to the        virtual network.    -   Load balancers, for example virtualized load balancer instances        that distribute network traffic among a group or cluster of        resource instances on a virtual network.    -   Network Address Translation (NAT) instances.    -   NAT gateways.    -   Network Access Control Lists (ACLs).    -   Network interfaces.    -   Route tables.    -   Subnets—A virtual network may be, but is not necessarily,        subdivided into two or more subnetworks, or subnets, for example        as illustrated in FIGS. 14 and 15.    -   Security groups—In some embodiments, the provider network may        allow a client to establish and manage virtual security groups        within the client's virtual network, within or across subnets,        for example as illustrated in FIG. 15. A security group is a        logical grouping of resource instances and acts as a virtual        firewall that controls the traffic allowed to reach one or more        resource instances within the security group according to        security group rules.    -   Regions—Provider network services and resources (e.g., virtual        networks, VM instances, data storage, gateways, load balancers,        etc.) may be supported in multiple geographic locations or        areas. As used herein, a region is a separate geographic area        that supports the provider network services and in which a        client may launch and configure resources. The services and APIs        may allow clients to launch or replicate their resources in one        or more regions.    -   Zones—Each region may include multiple, isolated locations,        referred to herein as zones. A client's resource instances may        be distributed across multiple zones within a region so that, if        a resource instance in one zone fails, an instance in another        zone can handle requests.

In some embodiments, clients may establish virtual networks 110 on theprovider network 100 that include instances of one or more of the abovenetworking primitives using respective provider network services 102.FIG. 1 illustrates an example virtual network 110 on a provider network100, and is not intended to be limiting. A client's virtual network 110may include resources instances 118 (e.g., VMs) that implement thefunctionality of the virtual network, for example application servers,web servers, database servers, and so on. The resources instances 118may include groups or clusters of instances 118A and 118B; for example,instances 118A may represent a production environment, while instances118B may represent a development environment. In some embodiments,instances 118A and 118B may be in different subnets and/or securitygroups.

A client's virtual network 110 may also include service instances 116(e.g., VMs) that implement particular provider network services in theclient's virtual network 110 such as application and operating systemlogging services, network monitoring and analysis services, coderepository services, container management services, and so on.

A client's virtual network 110 may also include access instances thatenable devices 182 on the client network 180 and other external entities190 to communicate with resources and endpoints within virtual network110 via an intermediate network 150 such as the Internet. Accessinstances may, for example, include load balancers and gateways(Internet gateways, NAT gateways, etc.). As shown in this example, insome embodiments the access instances may include HTTPS access instances114 and SSH access instances 112. HTTPS access instances 114 may includeinstances 114A and 114B for accessing resource instances 118A and 118B,respectively, from external entities 190 using the HTTPS protocol, aswell as instances 114C for accessing service instances 116 from devices182 on client network 180 using the HTTPS protocol. In some embodiments,a client may access resource instances in the virtual network 110 from adevice 182 (e.g., a console) on the client network 180, for exampleusing SSH. In some embodiments, to access a resource instance using SSH,the client is given an IP address of the instance and a key. The clientcan then directly SSH into the instance using the provided information.In some embodiments, an SSH access instance 112 may act as a proxy thatallows the client to access the client's resource instances on thevirtual network 110 from a device 182 (e.g., a console) on the clientnetwork 180 using the SSH protocol. For example, an SSH access instance112 may be in a publicly accessible subnet of the client's virtualnetwork. At least some of the client's resource instances may be in asubnet that is not publicly accessible. These resource instances may bein a security group that allows SSH access from a security groupattached to the SSH access instance 112. The client may connect to theSSH access instance 112 to connect to the client's resource instances.

As shown in FIG. 1, the provider network 100 may include a virtualnetwork verification service 130 implemented by one or more computingdevices on the provider network 100. In some embodiments, an instance ofvirtual network verification service 130 may be implemented on theclient's virtual network 100, for example by an SSH access instance 112as illustrated in FIG. 1. The virtual network verification service 130leverages a declarative logic programming language (e.g., Datalog) toallow the client to express queries, including recursive queries, abouttheir virtual networks on provider networks as constraint problems, andthat provides results for the queries by resolving the queries using aconstraint solver engine. FIG. 2 illustrates a virtual networkverification service 130, according to some embodiments.

Referring to FIG. 1, in the virtual network verification service 130,virtual networking semantics and logic for networking primitivesprovided by services 102 may be expressed and encoded as a set ofvirtual networking rules according to the logic programming language.The virtual networking rules may include rules that express commonrelationships and interactions among the various networking primitivesthat are implemented in virtual network 110. The virtual networkingrules may also incorporate rules that encode networking securitystandards (e.g., PCI, FedRAMP, HIPPA, etc.), or a client's internalsecurity standards or other networking requirements.

The virtual network verification service 130 obtains descriptiveinformation for the client's virtual network 110. The descriptiveinformation may, for example, identify instances of the networkingprimitives that are implemented in the virtual network 110, includedescriptions of the various instances (e.g., roles assigned toinstances, permissions granted to or denied to instances, IP addressesassigned to the instances, etc.), describe relationships among theinstances (e.g., paths between instances), and describe interfaces oraccess points to external entities 190. In some embodiments, the clientmay obtain the descriptive information from the virtual network 110 andprovide the descriptive information to the virtual network verificationservice 130, as shown in FIG. 3. Alternatively, in some embodiments, theclient may grant permission to the virtual network verification service130 to allow the virtual network verification service 130 to obtain thedescriptive information directly from the virtual network 110, as shownin FIG. 4. The virtual network verification service 130 may encode thedescriptive information as logic programs according to the declarativelogic programming language.

The virtual network verification service 130 leverages a declarativelogic programming language, and allows clients to pose queries abouttheir virtual networks 110 on the provider network 100, for example viaa graphical interface or a command line interface (CLI) to the service130 on a client device 182 in the client network 180. An example logicprogramming language that may be used in some embodiments is Datalog.Note that other declarative logic programming languages may be used. Insome embodiments, the queries may be posed in an expressive querylanguage that may be somewhat similar to SQL, but that applies tonetwork configurations. Alternatively, in some embodiments, the queriesmay be posed in human-friendly ways. The queries correspond to theoremsabout the generated logic programs and express constraint problems. Thevirtual network verification service 130 resolves the constraintproblems expressed by the queries for the encoded description accordingto the encoded rules using the constraint solver engine and provides theresults to the client. In some embodiments, the virtual networkverification service 130 may provide an API and interface for posingqueries. In some embodiments, the virtual network verification service130 may provide a set of standard queries that the client can select viathe API and interface. In some embodiments, the virtual networkverification service 130 may allow the client to compose and submitcustom queries via the API and interface.

The following describes example queries that may be posed by the clientabout the example virtual network shown in FIG. 1, and is not intendedto be limiting.

In some embodiments of a virtual network 110, resources on the virtualnetwork 110 should only be accessible via SSH through SSH accessinstance(s) 112 from designated endpoints on client network 180. Thus,the client may want to verify that no instances in virtual network 110are accessible via SSH from endpoints on the intermediate network 150.An example query to verify this may be expressed as:

all Instance: !internet-can-ssh-to-instance(Instance).

The client may also want to verify that, from the client network 180,the SSH access instance(s) 112 on the virtual network 110 are accessiblevia SSH. As previously noted, in some embodiments, at least some of aclient's instances in the virtual network 110 may be assigned particularroles; the roles may be indicated by tags stored in metadata for theinstances. The tags may be included in the descriptive information, andthus may be indicated in the encoded description for the virtual network110. Thus, in some embodiments tags may be used in queries, for exampleto verify that instances that are assigned particular roles can actuallyperform those roles. An example query to verify that, from the clientnetwork 180, the SSH access instance(s) 112 on the virtual network 110are accessible via SSH may be expressed as:

all Instance: atom/instance-tag(Instance, tag-key/Name,tag-value/SSHAccessInstance) <=>ClientNetwork-can-ssh-to-instance(Instance).

The above expression, when evaluated by the constraint solver, checksall instances on the virtual network 110; for instances that are taggedas SSHAccessInstance, the constraint solver determines if the instanceis reachable via SSH from the client network 180, returning TRUE if soand FALSE if not.

The following lists some other examples of aspects of the virtualnetwork 110 that a client may verify by posing appropriate queries tothe virtual network verification service 130, and is not intended to belimiting:

-   -   Only the SSH access instance(s) 112 are accessible via SSH from        the client network 180.    -   Resource instances 118A and 118B are reachable through their        respective HTTPS access instances 114A and 114B by external        entities 190 via intermediate network 150B (e.g., the Internet).    -   Resource instances 118A and 118B can reach intermediate network        150B to authenticate requests.    -   Resource instances 118A and 118B can write to specified service        instances 116.    -   Specified service instances 116 can be reached from the client        network 180 through HTTPS access instance(s) 114C.    -   Specified service instance 116 can reach specified endpoints on        the virtual network 110.    -   All instances are tagged with one of a set of specified tags.

FIG. 2 illustrates components and operation of an example virtualnetwork verification service, according to some embodiments. Virtualnetwork verification service 230 may be implemented by one or morecomputing devices on a provider network. In some embodiments, aninstance of virtual network verification service 230 may be implementedon the client's virtual network, for example by an SSH access instance112 as illustrated in FIG. 1. As shown in FIG. 2, in some embodiments,the virtual network verification service 230 may include a serviceengine 234, a constraint solver 236 engine, and an API 232. Serviceengine 234 may implement, but is not limited to, rules encoding 250logic, query processing 260 logic, and description encoding 270 logic.Constraint solver 236 is a declarative logic programming language engineconfigured to resolve queries, including recursive queries, about thevirtual network as represented by the encoded description 240 based onencoded virtual networking rules 238. API 232 exposes functionality ofthe service 210 to external entities including but not limited to theclient.

At (1A) and (1B) of FIG. 2, rules encoding 250 logic of the service 230may obtain (1A) and encode (1B) virtual networking rules 238 to beapplied to the virtual network. Rules to be encoded may be obtained fromthe service provider, from the client, or from other external entitiesor sources. Example encoded rules 238 are provided later in thisdocument.

In embodiments, virtual networking semantics and logic for thenetworking primitives used in virtual networks may be obtained andencoded as a set of virtual networking rules 238 according to the logicprogramming language. The virtual networking rules 238 may include rulesthat express common relationships and interactions among the variousnetworking primitives that may be implemented in virtual networks andthat are provided by the provider network's services and APIs. Thus,embodiments may provide, in one location or file, virtual networkingrules 238 that describe the logic of how virtual networking works in theprovider network environment.

In some embodiments, the virtual network verification service 230 mayobtain and encode rules for networking security standards such as thePayment Card Industry Data Security Standard (PCI DSS), the Federal Riskand Authorization Management Program (FedRAMP) standard, or the HealthInsurance Portability and Accountability Act (HIPPA) standard, and thussets of virtual networking rules 238 may be implemented that includerules for verifying networking security standards. In some embodiments,the virtual network verification service 230 may provide two or moredifferent sets of virtual networking rules 238 that each encodedifferent networking security standards that may be selectively used byclients to verify that their virtual networks conform to particularstandards. In some embodiments, the virtual network verification service230 may allow a client to define custom rules that encode the client'sinternal security standards, best practices, or other networkingrequirements, and thus sets of virtual networking rules 238 may beimplemented that include custom rules defined by the clients forapplication to their particular virtual network.

At (2) of FIG. 2, query processing 260 logic of the service 230 mayreceive a query from the client to be resolved for the virtual networkaccording to the virtual networking rules 238. In some embodiments, theclient may provide the query about their virtual network on the providernetwork via a graphical interface or a command line interface (CLI) tothe service API 232. In some embodiments, the query may be posed in anexpressive language that is similar to SQL, but that applies to networkconfigurations. Alternatively, in some embodiments, the queries may beposed in human-friendly ways. Example queries are described above inreference to FIG. 1.

At (3A) and (3B) of FIG. 2, description encoding 270 logic of theservice 230 may obtain (3A) and encode (3B) a description of the virtualnetwork. In some embodiments, description encoding 270 logic of theservice 230 obtains descriptive information (3A) for the virtual networkand encodes (3B) the descriptive information as an encoded description240 for each query it receives to insure that the description 240 isup-to-date when resolving the query. However, in some embodiments,description encoding 270 logic may obtain and encode descriptiveinformation for the virtual network, and process two or more queriesusing the encoded description 240. At (3A) of FIG. 2, descriptionencoding 270 logic of the service 230 obtains descriptive informationfor the client's virtual network. The descriptive information may, forexample, identify instances of the networking primitives that areimplemented in the virtual network, include descriptions of the variousinstances (e.g., roles assigned to instances, permissions granted ordenied to instances, IP addresses assigned to the instances, etc.),describe relationships among the instances (e.g., paths betweeninstances), and describe interfaces or access points to externalentities. In some embodiments, the client may obtain the descriptiveinformation from the virtual network and provide the descriptiveinformation to the virtual network verification service 230 with thequery, as shown in FIG. 3. Alternatively, in some embodiments, theclient may grant permission to the virtual network verification service230 to allow the virtual network verification service 230 to obtain thedescriptive information directly from the virtual network in response tothe query, as shown in FIG. 4. At (3B) of FIG. 2, description encoding270 logic of the service 230 may encode the obtained descriptiveinformation as logic programs according to the declarative logicprogramming language.

At (4) of FIG. 2, query processing 260 logic of the service 230 mayprovide the query to the constraint solver 236. The constraint solver236 resolves the constraint problem expressed by the query for theencoded description 240 according to the encoded rules 238, and at (5A)provides results (e.g., answers to the question posed by the query) toquery processing 260 which formats the results and provides theformatted results to the client via the API 232 at (5B). The formattedresults may include textual results (e.g., text that expresses an answerto a constraint posed by the query such as “YES”, “NO”, “TRUE”, or“FALSE”, a list of instances that meet a constraint posed by the query,etc.) and/or graphical results (e.g., a graphical representation of arelationship among two or more instances that was determined byresolving the query, a graphical representation of the virtual networkidentifying instances that were identified by resolving the query,etc.).

FIG. 3 illustrates a client providing descriptive information for avirtual network and queries to a virtual network verification servicethat processes the query and provides results to the client, accordingto some embodiments. At (1) of FIG. 3, the client, for example from aclient device 382 on the client network as illustrated in FIG. 1, mayobtain descriptive information from the client's virtual network 310 onthe provider network. For example, in some embodiments, one or moreprovider network services of the provider network that maintain metadatadescribing virtual networks may provide a DESCRIBE or similar call viarespective APIs that allow the client to request descriptive informationfor instances on their virtual network 310. At (2) of FIG. 3, the clientmay provide a query and the descriptive information to the serviceengine 334 of the provider network verification service 330 via serviceAPI 332. At (3A) of FIG. 3, the service engine 334 may encode theobtained descriptive information according to the declarative logicprogramming language, and provide the query and the encoded descriptionto the constraint solver 336. The constraint solver 336 resolves thequery for the encoded description according to the encoded virtualnetworking rules 338, and at (3B) provides results (e.g., answers to thequestion posed by the query) to service engine 334 which formats theresults and provides the formatted results to the client via the API 332at (4).

FIG. 4 illustrates a client providing queries and permission to access avirtual network to a virtual network verification service that obtainsdescriptive information from the virtual network, processes the query,and provides results to the client, according to some embodiments. At(1) of FIG. 4, the client, via a client account 488 with the providernetwork, may provide permission to the virtual network verificationservice 430 to obtain descriptive information from their virtual network410. For example, in some embodiments, one or more provider networkservices of the provider network that maintain metadata describingvirtual networks may provide DESCRIBE or similar calls via respectiveAPIs that allow the client to request descriptive information forinstances on their virtual network 410. The client may grant permissionto service 430 to allow the service 430 to perform the DESCRIBE calls tothe provider network service APIs for virtual network 410. In someembodiments, the client may grant only read permission for metadata ofinstances in the virtual network 410, and does not grant write or modifyprivileges for the metadata or for other data on or accessible throughthe virtual network 410. At (2) of FIG. 4, the client may provide aquery to the service engine 434 of the provider network verificationservice 430 via service API 432. At (3) of FIG. 4, in response to thequery, the service engine 434 may get descriptive information from theclient's virtual network 410, for example using DESCRIBE calls to one ormore provider network services that maintain metadata describing virtualnetworks via respective APIs. At (4A) of FIG. 4, the service engine 434may encode the obtained descriptive information according to thedeclarative logic programming language, and provide the query and theencoded description to the constraint solver 436. The constraint solver436 resolves the query for the encoded description according to theencoded virtual networking rules 438, and at (4B) provides results(e.g., answers to the question posed by the query) to service engine 434which formats the results and provides the formatted results to theclient via the API 432 at (5).

FIG. 5 is a high-level flowchart of a method for providing informationabout a virtual network to clients of a provider network, according tosome embodiments. As indicated at 1000, virtual networking rules may beobtained and encoded. Rules to be encoded may be obtained from theservice provider, from the client, or from other external entities orsources. The virtual networking rules may express virtual networkingsemantics and logic for the networking primitives used in virtualnetworks on the provider network. In some embodiments, the virtualnetworking rules may express rules for networking security standardssuch as the Payment Card Industry Data Security Standard (PCI DSS), theFederal Risk and Authorization Management Program (FedRAMP) standard, orthe Health Insurance Portability and Accountability Act (HIPPA). In someembodiments, the virtual networking rules may include client-definedrules that express the client's internal security standards or othernetworking requirements. Example encoded rules are provided later inthis document.

As indicated at 1010, the virtual network verification service mayreceive a query about a virtual network from the client. In embodiments,the virtual network verification service may be used by a client, via agraphical interface to the service on a console or via a command lineinterface (CLI), to obtain answers to questions (posed as queries,including recursive queries) about their virtual network on the providernetwork. In some embodiments, a query may be posed in an expressivelanguage that is similar to SQL, but that applies to networkconfigurations. Alternatively, in some embodiments, the queries may beposed in human-friendly ways. Example queries are described above inreference to FIG. 1.

As indicated at 1020, the virtual network verification service mayobtain and encode descriptive information about the virtual network. Thedescriptive information may, for example, identify instances of thenetworking primitives that are implemented in the virtual network,include descriptions of the instances (e.g., roles assigned tocomputation instances, permissions granted to or denied to resourceinstances, IP addresses assigned to the instances, etc.), describerelationships among the instances (e.g., paths between instances), anddescribe interfaces or access points to external entities (e.g.,computation instances that can be accessed by entities external to thevirtual network). In some embodiments, the client may obtain thedescriptive information from the virtual network and provide thedescriptive information to the virtual network verification service, asillustrated in FIG. 6. Alternatively, in some embodiments, the clientmay grant permission to the virtual network verification service toallow the virtual network verification service to obtain the descriptiveinformation directly from the virtual network, as illustrated in FIG. 7.The virtual network verification service may encode the descriptiveinformation as logic programs according to a declarative logicprogramming language (e.g., Datalog).

As indicated at 1030, the virtual network verification service mayresolve the query for the encoded description according to the encodedvirtual networking rules using a declarative logic programming language(e.g., Datalog) constraint solver engine. As indicated at 1040, resultsof the query resolution (e.g., answers to the question posed by thequery) may be formatted and provided to the client. The formattedresults may include textual results (e.g., text that expresses an answerto a constraint posed by the query such as “YES”, “NO”, “TRUE”, or“FALSE”, a list of instances that meet a constraint posed by the query,etc.) and/or graphical results (e.g., a graphical representation of arelationship among two or more instances that was determined byresolving the query, a graphical representation of the virtual networkidentifying instances that were identified by resolving the query,etc.).

As indicated by the arrow returning from element 1040 to element 1010,elements 1010-1040 may be iteratively performed to pose and resolvemultiple queries about the client's virtual network. In someembodiments, for example, the client may write a script that includes aseries of queries, and run the script to pose the queries to and receiveresults from the virtual network verification service. As shown in FIG.5, in some embodiments, the virtual network verification service mayobtain descriptive information for the virtual network and encode thedescriptive information as an encoded description for each query itreceives to insure that the description is up-to-date when resolving thequery. However, in some embodiments, the virtual network verificationservice may obtain and encode descriptive information for the virtualnetwork, and process two or more queries using the encoded description.

FIG. 6 is a flowchart of a method for providing information about avirtual network to clients of a provider network in which the clientprovides descriptive information and queries to a virtual networkverification service, according to some embodiments. As indicated at1100, the client obtains descriptive information from the virtualnetwork, for example using DESCRIBE calls provided by provider networkservice APIs. As indicated at 1110, the client sends a query and thedescriptive information to the virtual network verification service. Asindicated at 1120, the verification service encodes the descriptiveinformation about the virtual network. As indicated at 1130, theverification service resolves the query for the encoded descriptionaccording to the encoded virtual network rules using the constraintsolver engine. As indicated at 1140, the virtual network verificationservice provides results of the query resolution to the client.

FIG. 7 is a flowchart of a method for providing information about avirtual network to clients of a provider network in which the clientprovides descriptive information and permissions to access a virtualnetwork to a virtual network verification service, according to someembodiments. As indicated at 1200, the client grants permission to thevirtual network verification service allowing the service to obtaindescriptive information from the virtual network, for example permissionto use DESCRIBE calls to one or more provider network services thatmaintain metadata describing virtual networks to obtain information forthe virtual network. As indicated at 1210, the client sends a query tothe virtual network verification service. As indicated at 1220, thevirtual network verification service obtains descriptive informationfrom the virtual network, for example using DESCRIBE calls to one ormore provider network services that maintain metadata describing virtualnetworks. As indicated at 1230, the virtual network verification serviceencodes the descriptive information about the virtual network. Asindicated at 1240, the virtual network verification service resolves thequery for the encoded description according to the rules using theconstraint solver engine. As indicated at 1250, the virtual networkverification service provides results of the query resolution to theclient.

FIG. 8 illustrates a client's virtual network implementation in aprovider network environment that includes two or more peered virtualnetworks, according to some embodiments. FIG. 8 is provided in part todescribe example virtual networking rules that may be used in a virtualnetwork verification service 2030 as described herein. As shown in FIG.8, a client's virtual network implementation 2010 on a provider network2000 may include two or more virtual networks 2020. FIG. 8 shows twovirtual networks 2020A and 2020B in a client's virtual networkimplementation 2010. In some embodiments, virtual networks 2020A and2020B may each include one or more subnets, and security groups may beestablished in virtual networks 2020A and 2020B (see, e.g., FIGS. 14 and15). Network endpoints 2022A and 2022B represent network interfaces ofthe various instances of networking primitives (e.g., resourceinstances) in respective virtual networks 2020A and 2020B. A peeringconnection 2024 may be established over provider network 2000 betweenvirtual networks 2020A and 2020B that allows instances on the virtualnetworks 2020A and 2020B to securely communicate over the providernetwork 2000 without having to traverse an external network 2050 such asthe Internet.

Example rules for “private routing” are given below. These example arenot intended to be limiting. “Routing” as used in these examples means,in the absence of firewalls, can IP packets flow from one endpoint 2022to another endpoint 2022. Routing between two endpoints 2022 within thevirtual network implementation 2010 may be referred to as “privaterouting.” The rules may be different depending on whether both endpoints2022 are in the same virtual network 2020 or in different virtualnetworks 2020 in the virtual network implementation 2010. The followingdescribes example rules according to a descriptive logic programminglanguage for determining if packets can flow between two endpoints 2022in a virtual network implementation 2010:

routable-private: endpoint -> endpoint -> type -: routable-privateEndpoint1 Endpoint2 <- routable-private-one-way Endpoint1 Endpoint2 <-routable-private-one-way Endpoint2 Endpoint1

The first line defines the type for endpoints. Endpoint1 and Endpoint2are variables. The rule (routable-private Endpoint1 Endpoint2) evaluatesas true if (routable-private-one-way Endpoint1 Endpoint2) AND(routable-private-one-way Endpoint2 Endpoint1) are both true (and falseotherwise). For routing between endpoints 2022 within a virtual network2020, the rule routable-private-one-way may be defined as:

routable-private-one-way: endpoint -> endpoint -> type -:routable-private-one-way Endpoint1 Endpoint2 <-endpoint-has-virtual-network Endpoint1 Vnetwork <-endpoint-has-virtual-network Endpoint2 Vnetwork

Endpoint1 and Endpoint2 are variables. Vnetwork is the same variable(i.e., indicates the same virtual network 2020). This rule evaluates astrue if both Endpoint1 and Endpoint2 are in the same virtual network2020 (and false otherwise).

For routing between endpoints 2022 in different virtual networks 2020through a peering connection 2024, the rule routable-private-one-way maybe defined as follows. The text preceded by “//” are comments:

-: routable-private-one-way Endpoint1 Endpoint2 // look up the IPs ofthe endpoints <- endpoint-has-private-ip Endpoint1 Ip1 <- endpoint-has-private-ip Endpoint1 Ip2 // look up the virtual networks of theendpoints <- endpoint-has-virtual-network Endpoint1 Vnetwork1 <-endpoint-has-virtual-network Endpoint2 Vnetwork2 // look up the CIDRs(classless inter-domain routing) of the peering <- peered-cidrs PcxVnetwork1 Cidr1 Vnetwork2 Cidr2 // look up the source endpoint's routetable <- endpoint-has-rtb Endpoint1 Rtb1 // look up the CIDR of theroute in the table, and verify the route is active <- atom/pcx-routeRtb1 Pcx Cidr3 route-state/active // make sure all three CIDRs matchrespective IPs <- cidr-matches-private-ip Cidr1 Ip1 <-cidr-matches-private-ip Cidr2 Ip2 <- cidr-matches-private-ip Cidr3 Ip2Synthesizing Virtual Networks

In some embodiments, the virtual network verification service can beused in automatically synthesizing a virtual network that satisfiesconstraints, for example constraints posed in queries, so that theclient does not have to build and test the virtual network themselves.For example, a client may want to establish a virtual network thatcomplies with a particular networking security standard and/or withclient-specified networking standards and that contains a specified setof networking primitives. Constraints imposed by the standards can beposed as queries, and the queries can be resolved to determine a virtualnetwork configuration that satisfies the constraints, or alternativelyto determine if the configuration of a virtual network conforms to theconstraints. A virtual network that conforms to the constraints may thenbe synthesized, or alternatively a virtual network may be modified toconform to the constraints.

FIG. 9 is a flowchart of a method for automatically synthesizing virtualnetworks for clients, according to some embodiments. As indicated at3000, the client specifies a set of networking primitives and poses aset of queries that specify the constraints for a desired virtualnetwork. As indicated at 3010, the verification service determines avirtual network configuration that includes the set of networkingprimitives and that satisfies the constraints specified by the queriesaccording to a set of virtual networking rules. As indicated at 3020, avirtual network may then be generated on the provider network accordingto the virtual network configuration through appropriate providernetwork services.

FIG. 10 is a flowchart of another method for automatically synthesizingvirtual networks for clients, according to some embodiments. Asindicated at 3100, the client specifies an existing virtual network andposes a set of queries that specify constraints for the virtual network.As indicated at 3110, the verification service resolves the queries todetermine if the virtual network satisfies the constraints specified bythe queries according to a set of virtual networking rules. At 3120, ifthe existing virtual network satisfies the constraints, then the clientmay be informed, and the method is done. At 3120, if the existingvirtual network does not satisfy the constraints, then a new virtualnetwork that conforms to the constraints may be generated on theprovider network through appropriate provider network services.Alternatively, in some embodiments, the existing virtual network may bemodified through appropriate provider network services to satisfy theconstraints.

Example Provider Network Environment

This section describes example provider network environments in whichembodiments of the methods and apparatus described in reference to FIGS.1 through 10 may be implemented. However, these example provider networkenvironments are not intended to be limiting.

FIG. 11 illustrates an example provider network environment, accordingto some embodiments. A provider network 4000 may provide resourcevirtualization to clients via one or more virtualization services 4010that allow clients to purchase, rent, or otherwise obtain instances 4012of virtualized resources, including but not limited to computation andstorage resources, implemented on devices within the provider network ornetworks in one or more data centers. Private IP addresses 4016 may beassociated with the resource instances 4012; the private IP addressesare the internal network addresses of the resource instances 4012 on theprovider network 4000. In some embodiments, the provider network 4000may also provide public IP addresses 4014 and/or public IP addressranges (e.g., Internet Protocol version 4 (IPv4) or Internet Protocolversion 6 (IPv6) addresses) that clients may obtain from the provider4000.

Conventionally, the provider network 4000, via the virtualizationservices 4010, may allow a client of the service provider (e.g., aclient that operates client network 4050A) to dynamically associate atleast some public IP addresses 4014 assigned or allocated to the clientwith particular resource instances 4012 assigned to the client. Theprovider network 4000 may also allow the client to remap a public IPaddress 4014, previously mapped to one virtualized computing resourceinstance 4012 allocated to the client, to another virtualized computingresource instance 4012 that is also allocated to the client. Using thevirtualized computing resource instances 4012 and public IP addresses4014 provided by the service provider, a client of the service providersuch as the operator of client network 4050A may, for example, implementclient-specific applications and present the client's applications on anintermediate network 4040, such as the Internet. Other network entities4020 on the intermediate network 4040 may then generate traffic to adestination public IP address 4014 published by the client network4050A; the traffic is routed to the service provider data center, and atthe data center is routed, via a network substrate, to the private IPaddress 4016 of the virtualized computing resource instance 4012currently mapped to the destination public IP address 4014. Similarly,response traffic from the virtualized computing resource instance 4012may be routed via the network substrate back onto the intermediatenetwork 4040 to the source entity 4020.

Private IP addresses, as used herein, refer to the internal networkaddresses of resource instances in a provider network. Private IPaddresses are only routable within the provider network. Network trafficoriginating outside the provider network is not directly routed toprivate IP addresses; instead, the traffic uses public IP addresses thatare mapped to the resource instances. The provider network may includenetwork devices or appliances that provide network address translation(NAT) or similar functionality to perform the mapping from public IPaddresses to private IP addresses and vice versa.

Public IP addresses, as used herein, are Internet routable networkaddresses that are assigned to resource instances, either by the serviceprovider or by the client. Traffic routed to a public IP address istranslated, for example via 1:1 network address translation (NAT), andforwarded to the respective private IP address of a resource instance.

Some public IP addresses may be assigned by the provider networkinfrastructure to particular resource instances; these public IPaddresses may be referred to as standard public IP addresses, or simplystandard IP addresses. In some embodiments, the mapping of a standard IPaddress to a private IP address of a resource instance is the defaultlaunch configuration for all resource instance types.

At least some public IP addresses may be allocated to or obtained byclients of the provider network 4000; a client may then assign theirallocated public IP addresses to particular resource instances allocatedto the client. These public IP addresses may be referred to as clientpublic IP addresses, or simply client IP addresses. Instead of beingassigned by the provider network 4000 to resource instances as in thecase of standard IP addresses, client IP addresses may be assigned toresource instances by the clients, for example via an API provided bythe service provider. Unlike standard IP addresses, client IP Addressesare allocated to client accounts and can be remapped to other resourceinstances by the respective clients as necessary or desired. A client IPaddress is associated with a client's account, not a particular resourceinstance, and the client controls that IP address until the clientchooses to release it. Unlike conventional static IP addresses, clientIP addresses allow the client to mask resource instance or availabilityzone failures by remapping the client's public IP addresses to anyresource instance associated with the client's account. The client IPaddresses, for example, enable a client to engineer around problems withthe client's resource instances or software by remapping client IPaddresses to replacement resource instances.

FIG. 12 illustrates an example data center that implements an overlaynetwork on a network substrate using IP tunneling technology, accordingto some embodiments. A provider data center 4100 may include a networksubstrate that includes networking devices 4112 such as routers,switches, network address translators (NATs), and so on. Someembodiments may employ an Internet Protocol (IP) tunneling technology toprovide an overlay network via which encapsulated packets may be passedthrough network substrate 4110 using tunnels. The IP tunnelingtechnology may provide a mapping and encapsulating system for creatingan overlay network on a network (e.g., a local network in data center4100 of FIG. 12) and may provide a separate namespace for the overlaylayer (the public IP addresses) and the network substrate 4110 layer(the private IP addresses). Packets in the overlay layer may be checkedagainst a mapping directory (e.g., provided by mapping service 4130) todetermine what their tunnel substrate target (private IP address) shouldbe. The IP tunneling technology provides a virtual network topology (theoverlay network); the interfaces (e.g., service APIs) that are presentedto clients are attached to the overlay network so that when a clientprovides an IP address to which the client wants to send packets, the IPaddress is run in virtual space by communicating with a mapping service(e.g., mapping service 4130) that knows where the IP overlay addressesare.

In some embodiments, the IP tunneling technology may map IP overlayaddresses (public IP addresses) to substrate IP addresses (private IPaddresses), encapsulate the packets in a tunnel between the twonamespaces, and deliver the packet to the correct endpoint via thetunnel, where the encapsulation is stripped from the packet. In FIG. 12,an example overlay network tunnel 4134A from a virtual machine (VM)4124A on host 4120A to a device on the intermediate network 4150 and anexample overlay network tunnel 4134B between a VM 4124B on host 4120Band a VM 4124C on host 4120C are shown. In some embodiments, a packetmay be encapsulated in an overlay network packet format before sending,and the overlay network packet may be stripped after receiving. In otherembodiments, instead of encapsulating packets in overlay networkpackets, an overlay network address (public IP address) may be embeddedin a substrate address (private IP address) of a packet before sending,and stripped from the packet address upon receiving. As an example, theoverlay network may be implemented using 32-bit IPv4 (Internet Protocolversion 4) addresses as the public IP addresses, and the IPv4 addressesmay be embedded as part of 128-bit IPv6 (Internet Protocol version 6)addresses used on the substrate network as the private IP addresses.

Referring to FIG. 12, at least some networks in which embodiments may beimplemented may include hardware virtualization technology that enablesmultiple operating systems to run concurrently on a host computer (e.g.,hosts 4120A and 4120B of FIG. 12), i.e. as virtual machines (VMs) 4124on the hosts 4120. The VMs 4124 may, for example, be rented or leased toclients of a network provider. A hypervisor, or virtual machine monitor(VMM) 4122, on a host 4120 presents the VMs 4124 on the host with avirtual platform and monitors the execution of the VMs 4124. Each VM4124 may be provided with one or more private IP addresses; the VMM 4122on a host 4120 may be aware of the private IP addresses of the VMs 4124on the host. A mapping service 4130 may be aware of all network IPprefixes and the IP addresses of routers or other devices serving IPaddresses on the local network. This includes the IP addresses of theVMMs 4122 serving multiple VMs 4124. The mapping service 4130 may becentralized, for example on a server system, or alternatively may bedistributed among two or more server systems or other devices on thenetwork. A network may, for example, use the mapping service technologyand IP tunneling technology to, for example, route data packets betweenVMs 4124 on different hosts 4120 within the data center 4100 network;note that an interior gateway protocol (IGP) may be used to exchangerouting information within such a local network.

In addition, a network such as the provider data center 4100 network(which is sometimes referred to as an autonomous system (AS)) may usethe mapping service technology, IP tunneling technology, and routingservice technology to route packets from the VMs 4124 to Internetdestinations, and from Internet sources to the VMs 4124. Note that anexternal gateway protocol (EGP) or border gateway protocol (BGP) istypically used for Internet routing between sources and destinations onthe Internet. FIG. 12 shows an example provider data center 4100implementing a network that provides resource virtualization technologyand that provides full Internet access via edge router(s) 4114 thatconnect to Internet transit providers, according to some embodiments.The provider data center 4100 may, for example, provide clients theability to implement virtual computing systems (VMs 4124) via a hardwarevirtualization service and the ability to implement virtualized datastores 4116 on storage resources 4118 via a storage virtualizationservice.

The data center 4100 network may implement IP tunneling technology,mapping service technology, and a routing service technology to routetraffic to and from virtualized resources, for example to route packetsfrom the VMs 4124 on hosts 4120 in data center 4100 to Internetdestinations, and from Internet sources to the VMs 4124. Internetsources and destinations may, for example, include computing systems4170 connected to the intermediate network 4140 and computing systems4152 connected to local networks 4150 that connect to the intermediatenetwork 4140 (e.g., via edge router(s) 4114 that connect the network4150 to Internet transit providers). The provider data center 4100network may also route packets between resources in data center 4100,for example from a VM 4124 on a host 4120 in data center 4100 to otherVMs 4124 on the same host or on other hosts 4120 in data center 4100.

A service provider that provides data center 4100 may also provideadditional data center(s) 4160 that include hardware virtualizationtechnology similar to data center 4100 and that may also be connected tointermediate network 4140. Packets may be forwarded from data center4100 to other data centers 4160, for example from a VM 4124 on a host4120 in data center 4100 to another VM on another host in another,similar data center 4160, and vice versa.

While the above describes hardware virtualization technology thatenables multiple operating systems to run concurrently on host computersas virtual machines (VMs) on the hosts, where the VMs may be rented orleased to clients of the network provider, the hardware virtualizationtechnology may also be used to provide other computing resources, forexample storage resources 4118, as virtualized resources to clients of anetwork provider in a similar manner.

FIG. 13 is a block diagram of an example provider network that providesa storage virtualization service and a hardware virtualization serviceto clients, according to some embodiments. Hardware virtualizationservice 4220 provides multiple computation resources 4224 (e.g., VMs) toclients. The computation resources 4224 may, for example, be rented orleased to clients of the provider network 4200 (e.g., to a client thatimplements client network 4250). Each computation resource 4224 may beprovided with one or more private IP addresses. Provider network 4200may be configured to route packets from the private IP addresses of thecomputation resources 4224 to public Internet destinations, and frompublic Internet sources to the computation resources 4224.

Provider network 4200 may provide a client network 4250, for examplecoupled to intermediate network 4240 via local network 4256, the abilityto implement virtual computing systems 4292 via hardware virtualizationservice 4220 coupled to intermediate network 4240 and to providernetwork 4200. In some embodiments, hardware virtualization service 4220may provide one or more APIs 4202, for example a web services interface,via which a client network 4250 may access functionality provided by thehardware virtualization service 4220, for example via a console 4294. Insome embodiments, at the provider network 4200, each virtual computingsystem 4292 at client network 4250 may correspond to a computationresource 4224 that is leased, rented, or otherwise provided to clientnetwork 4250.

From an instance of a virtual computing system 4292 and/or anotherclient device 4290 or console 4294, the client may access thefunctionality of storage virtualization service 4210, for example viaone or more APIs 4202, to access data from and store data to a virtualdata store 4216 provided by the provider network 4200. In someembodiments, a virtualized data store gateway (not shown) may beprovided at the client network 4250 that may locally cache at least somedata, for example frequently accessed or critical data, and that maycommunicate with virtualized data store service 4210 via one or morecommunications channels to upload new or modified data from a localcache so that the primary store of data (virtualized data store 4216) ismaintained. In some embodiments, a user, via a virtual computing system4292 and/or on another client device 4290, may mount and access virtualdata store 4216 volumes, which appear to the user as local virtualizedstorage 4298.

While not shown in FIG. 13, the virtualization service(s) may also beaccessed from resource instances within the provider network 4200 viaAPI(s) 4202. For example, a client, appliance service provider, or otherentity may access a virtualization service from within a respectivevirtual network on the provider network 4200 via an API 4202 to requestallocation of one or more resource instances within the virtual networkor within another virtual network.

FIG. 14 illustrates an example provider network that provides virtualnetworks on the provider network to at least some clients, according tosome embodiments. A client's virtual network 4360 on a provider network4300, for example, enables a client to connect their existinginfrastructure (e.g., devices 4352) on client network 4350 to a set oflogically isolated resource instances (e.g., VMs 4324A and 4324B andstorage 4318A and 4318B), and to extend management capabilities such assecurity services, firewalls, and intrusion detection systems to includetheir resource instances.

A client's virtual network 4360 may be connected to a client network4350 via a private communications channel 4342. A private communicationschannel 4342 may, for example, be a tunnel implemented according to anetwork tunneling technology or some other technology over anintermediate network 4340. The intermediate network may, for example, bea shared network or a public network such as the Internet.Alternatively, a private communications channel 4342 may be implementedover a direct, dedicated connection between virtual network 4360 andclient network 4350.

A public network may be broadly defined as a network that provides openaccess to and interconnectivity among a plurality of entities. TheInternet, or World Wide Web (WWW) is an example of a public network. Ashared network may be broadly defined as a network to which access islimited to two or more entities, in contrast to a public network towhich access is not generally limited. A shared network may, forexample, include one or more local area networks (LANs) and/or datacenter networks, or two or more LANs or data center networks that areinterconnected to form a wide area network (WAN). Examples of sharednetworks may include, but are not limited to, corporate networks andother enterprise networks. A shared network may be anywhere in scopefrom a network that covers a local area to a global network. Note that ashared network may share at least some network infrastructure with apublic network, and that a shared network may be coupled to one or moreother networks, which may include a public network, with controlledaccess between the other network(s) and the shared network. A sharednetwork may also be viewed as a private network, in contrast to a publicnetwork such as the Internet. In some embodiments, either a sharednetwork or a public network may serve as an intermediate network betweena provider network and a client network.

To establish a virtual network 4360 for a client on provider network4300, one or more resource instances (e.g., VMs 4324A and 4324B andstorage 4318A and 4318B) may be allocated to the virtual network 4360.Note that other resource instances (e.g., storage 4318C and VMs 4324C)may remain available on the provider network 4300 for other clientusage. A range of public IP addresses may also be allocated to thevirtual network 4360. In addition, one or more networking devices(routers, switches, etc.) of the provider network 4300 may be allocatedto the virtual network 4360. A private communications channel 4342 maybe established between a private gateway 4362 at virtual network 4360and a gateway 4356 at client network 4350.

In some embodiments, in addition to, or instead of, a private gateway4362, virtual network 4360 may include a public gateway 4364 thatenables resources within virtual network 4360 to communicate directlywith entities (e.g., network entity 4344) via intermediate network 4340,and vice versa, instead of or in addition to via private communicationschannel 4342.

Virtual network 4360 may be, but is not necessarily, subdivided into twoor more subnetworks, or subnets, 4370. For example, in implementationsthat include both a private gateway 4362 and a public gateway 4364, avirtual network 4360 may be subdivided into a subnet 4370A that includesresources (VMs 4324A and storage 4318A, in this example) reachablethrough private gateway 4362, and a subnet 4370B that includes resources(VMs 4324B and storage 4318B, in this example) reachable through publicgateway 4364.

The client may assign particular client public IP addresses toparticular resource instances in virtual network 4360. A network entity4344 on intermediate network 4340 may then send traffic to a public IPaddress published by the client; the traffic is routed, by the providernetwork 4300, to the associated resource instance. Return traffic fromthe resource instance is routed, by the provider network 4300, back tothe network entity 4344 over intermediate network 4340. Note thatrouting traffic between a resource instance and a network entity 4344may require network address translation to translate between the publicIP address and the private IP address of the resource instance.

Some embodiments may allow a client to remap public IP addresses in aclient's virtual network 4360 as illustrated in FIG. 14 to devices onthe client's external network 4350. When a packet is received (e.g.,from network entity 4344), the network 4300 may determine that thedestination IP address indicated by the packet has been remapped to anendpoint on external network 4350 and handle routing of the packet tothe respective endpoint, either via private communications channel 4342or via the intermediate network 4340. Response traffic may be routedfrom the endpoint to the network entity 4344 through the providernetwork 4300, or alternatively may be directly routed to the networkentity 4344 by the client network 4350. From the perspective of thenetwork entity 4344, it appears as if the network entity 4344 iscommunicating with the public IP address of the client on the providernetwork 4300. However, the network entity 4344 has actually communicatedwith the endpoint on client network 4350.

While FIG. 14 shows network entity 4344 on intermediate network 4340 andexternal to provider network 4300, a network entity may be an entity onprovider network 4300. For example, one of the resource instancesprovided by provider network 4300 may be a network entity that sendstraffic to a public IP address published by the client.

FIG. 15 illustrates subnets and security groups in an example virtualnetwork on a provider network, according to some embodiments. In someembodiments, a provider network such as provider network 4300 in FIG. 14may allow the client to establish and manage virtual security groups4416 within the client's virtual network 4410, within or across subnets4414. A security group 4416 is a logical grouping of resource instances4418 and acts as a virtual firewall that controls the traffic allowed toreach one or more resource instances 4418 within the security group 4416according to security group rules. The client may establish one or moresecurity groups 4416 within the virtual network 4410, and may associateeach resource instance 4418 in the virtual network 4410 with one or moreof the security groups 4416. In some embodiments, the client mayestablish and/or modify rules for each security group 4416 that controlthe inbound traffic allowed to reach the resource instances 4418associated with the security group 4416.

In the example virtual network 4410 shown in FIG. 15, the virtualnetwork 4410 is subdivided into two subnets 4414A and 4414B. Access tothe virtual network 4410 is controlled by gateway(s) 4430. Each subnet4414 may include at least one router 4412 that acts to route traffic to(and from) resource instances 4418 on the respective subnet 4414. Insome embodiments, network access control lists (ACLs) may be used tocontrol access to the subnets 4414 at router(s) 4412. In the exampleshown in FIG. 15, resource instances 4418A through 4418E are on subnet4414A, and resource instances 4418F through 4418J are on subnet 4414B.The client has established four security groups 4416A through 4416D. Asshown in FIG. 15, a security group may extend across subnets 4414, asdoes security group 4416A that includes resource instances 4418A and4418B on subnet 4414A and resource instance 4418F on subnet 4414B. Inaddition, a resource instance 4418 may be included in two or moresecurity groups 4416, as is resource instance 4418A which is included insecurity group 4416A and 4416B.

Illustrative System

In some embodiments, a system that implements a portion or all of themethods and apparatus for verifying virtual networks in provider networkenvironments as described herein may include a general-purpose computersystem that includes or is configured to access one or morecomputer-accessible media, such as computer system 5000 illustrated inFIG. 16. In the illustrated embodiment, computer system 5000 includesone or more processors 5010 coupled to a system memory 5020 via aninput/output (I/O) interface 5030. Computer system 5000 further includesa network interface 5040 coupled to I/O interface 5030.

In various embodiments, computer system 5000 may be a uniprocessorsystem including one processor 5010, or a multiprocessor systemincluding several processors 5010 (e.g., two, four, eight, or anothersuitable number). Processors 5010 may be any suitable processors capableof executing instructions. For example, in various embodiments,processors 5010 may be general-purpose or embedded processorsimplementing any of a variety of instruction set architectures (ISAs),such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitableISA. In multiprocessor systems, each of processors 5010 may commonly,but not necessarily, implement the same ISA.

System memory 5020 may be configured to store instructions and dataaccessible by processor(s) 5010. In various embodiments, system memory5020 may be implemented using any suitable memory technology, such asstatic random access memory (SRAM), synchronous dynamic RAM (SDRAM),nonvolatile/Flash-type memory, or any other type of memory. In theillustrated embodiment, program instructions and data implementing oneor more desired functions, such as those methods, techniques, and datadescribed above for providing client-defined rules for clients'resources in provider network environments, are shown stored withinsystem memory 5020 as code 5025 and data 5026.

In one embodiment, I/O interface 5030 may be configured to coordinateI/O traffic between processor 5010, system memory 5020, and anyperipheral devices in the device, including network interface 5040 orother peripheral interfaces. In some embodiments, I/O interface 5030 mayperform any necessary protocol, timing or other data transformations toconvert data signals from one component (e.g., system memory 5020) intoa format suitable for use by another component (e.g., processor 5010).In some embodiments, I/O interface 5030 may include support for devicesattached through various types of peripheral buses, such as a variant ofthe Peripheral Component Interconnect (PCI) bus standard or theUniversal Serial Bus (USB) standard, for example. In some embodiments,the function of I/O interface 5030 may be split into two or moreseparate components, such as a north bridge and a south bridge, forexample. Also, in some embodiments some or all of the functionality ofI/O interface 5030, such as an interface to system memory 5020, may beincorporated directly into processor 5010.

Network interface 5040 may be configured to allow data to be exchangedbetween computer system 5000 and other devices 5060 attached to anetwork or networks 5050, such as other computer systems or devices asillustrated in FIGS. 1 through 15, for example. In various embodiments,network interface 5040 may support communication via any suitable wiredor wireless general data networks, such as types of Ethernet network,for example. Additionally, network interface 5040 may supportcommunication via telecommunications/telephony networks such as analogvoice networks or digital fiber communications networks, via storagearea networks such as Fibre Channel SANs, or via any other suitable typeof network and/or protocol.

In some embodiments, system memory 5020 may be one embodiment of acomputer-accessible medium configured to store program instructions anddata as described above for FIGS. 1 through 10 for implementingembodiments of methods and apparatus for verifying virtual networks inprovider network environments. However, in other embodiments, programinstructions and/or data may be received, sent or stored upon differenttypes of computer-accessible media. Generally speaking, acomputer-accessible medium may include non-transitory storage media ormemory media such as magnetic or optical media, e.g., disk or DVD/CDcoupled to computer system 5000 via I/O interface 5030. A non-transitorycomputer-accessible storage medium may also include any volatile ornon-volatile media such as RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM,etc.), ROM, etc., that may be included in some embodiments of computersystem 5000 as system memory 5020 or another type of memory. Further, acomputer-accessible medium may include transmission media or signalssuch as electrical, electromagnetic, or digital signals, conveyed via acommunication medium such as a network and/or a wireless link, such asmay be implemented via network interface 5040.

CONCLUSION

Various embodiments may further include receiving, sending or storinginstructions and/or data implemented in accordance with the foregoingdescription upon a computer-accessible medium. Generally speaking, acomputer-accessible medium may include storage media or memory mediasuch as magnetic or optical media, e.g., disk or DVD/CD-ROM, volatile ornon-volatile media such as RAM (e.g. SDRAM, DDR, RDRAM, SRAM, etc.),ROM, etc., as well as transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as network and/or a wireless link.

The various methods as illustrated in the Figures and described hereinrepresent exemplary embodiments of methods. The methods may beimplemented in software, hardware, or a combination thereof. The orderof method may be changed, and various elements may be added, reordered,combined, omitted, modified, etc.

Various modifications and changes may be made as would be obvious to aperson skilled in the art having the benefit of this disclosure. It isintended to embrace all such modifications and changes and, accordingly,the above description to be regarded in an illustrative rather than arestrictive sense.

What is claimed is:
 1. A computer system including a processor coupledto a memory, the memory including instructions for a virtual networkverification service that upon execution causes the system to: receive aquery about a virtual network of a plurality of virtual networks from aparticular client of a plurality of clients via a client device, whereinthe query is expressed as a constraint problem, wherein the virtualnetwork is instantiated for the particular client in a provider networkand includes virtual machines, and wherein the provider network hoststhe plurality of virtual networks for respective clients of theplurality of clients on a substrate network of the provider network;obtain rules for the particular client's virtual network, wherein one ormore different rules apply to different individual ones of the pluralityof virtual networks; encode the rules for the particular client'svirtual network according to a declarative logic programming language togenerate encoded virtual networking rules for the particular client'svirtual network; and in response to the query: obtain descriptiveinformation for the particular client's virtual network; encode thedescriptive information for the particular client's virtual networkaccording to the declarative logic programming language to generate anencoded description of the particular client's virtual network; resolvethe query for the encoded description of the particular client's virtualnetwork according to the encoded virtual networking rules using aconstraint solver program, wherein the constraint solver program isconfigured to resolve constraint problems according to the declarativelogic programming language and according to the encoded virtualnetworking rules; and provide results of the query resolution about theparticular client's virtual network to the client device.
 2. The systemas recited in claim 1, wherein the memory further comprises instructionsthat upon execution cause the system to obtain the descriptiveinformation from an application program interface of the providernetwork.
 3. The system as recited in claim 1, wherein, the instructionsthat upon execution cause the system to obtain the descriptiveinformation further comprise instructions that upon execution cause thesystem to: receive permission from the particular client to obtain thedescriptive information for the particular client's virtual network fromone or more provider network services; and obtain the descriptiveinformation for the particular client's virtual network on the providernetwork from the one or more provider network services.
 4. The system asrecited in claim 1, wherein the descriptive information comprises one ormore of information identifying instances of networking primitives thatare implemented in the particular client's virtual network, descriptionsof the virtual machines in the particular client's virtual network,descriptions of relationships among the virtual machines in theparticular client's virtual network, or descriptions of interfaces toentities external to the particular client's virtual network.
 5. Thesystem as recited in claim 1, wherein the virtual networking rules forthe particular client's virtual network include one or more of rulesthat encode virtual networking semantics and logic for networkingprimitives implemented in the particular client's virtual network, rulesthat encode one or more networking security standards, or client-definedrules that encode the client's networking requirements.
 6. The system asrecited in claim 1, wherein the queries are posed to verify that pathsbetween virtual machines in the particular client's virtual network andother virtual machines in the particular client's virtual network areopen, to verify that paths between virtual machines in the particularclient's virtual network and one or more entities external to theparticular client's virtual network are open, or to verify that virtualmachines in the particular client's virtual network are not accessibleby entities that should not have access to the virtual machines.
 7. Thesystem as recited in claim 1, wherein the results include one or more ofa textual representation of the results of the query resolution aboutthe particular client's virtual network or a graphical representation ofthe results of the query resolution about the particular client'svirtual network.
 8. A method, comprising: performing, by a virtualnetwork verification service implemented by one or more devices on aprovider network: receiving a query about a client's virtual network onthe provider network, wherein the query expresses a constraint problem,and wherein the provider network hosts a plurality of virtual networksfor respective clients of a plurality of clients; obtain rules for theclient's virtual network, wherein one or more different rules apply todifferent individual ones of the plurality of virtual networks; encodethe rules for the client's virtual network according to a declarativelogic programming language to generate encoded virtual networking rulesfor the client's virtual network; obtaining descriptive information forthe client's virtual network; encoding the descriptive information forthe client's virtual network according to the declarative logicprogramming language to generate an encoded description of the client'svirtual network; resolving the query for the encoded description of theclient's virtual network according to the encoded virtual networkingrules using a constraint solver engine; and providing results of thequery resolution about the client's virtual network to the client. 9.The method as recited in claim 8, wherein the descriptive information isobtained from the client.
 10. The method as recited in claim 8, whereinobtaining the descriptive information comprises: obtaining permissionfrom the client to get the descriptive information for the client'svirtual network from one or more provider network services; andobtaining the descriptive information for the client's virtual networkon the provider network from the one or more provider network services.11. The method as recited in claim 8, wherein the descriptiveinformation comprises one or more of information identifying instancesof networking primitives that are implemented in the client's virtualnetwork, descriptions of virtual machines in the client's virtualnetwork, descriptions of relationships among the virtual machines in theclient's virtual network, or descriptions of interfaces to entitiesexternal to the client's virtual network.
 12. The method as recited inclaim 8, wherein the virtual networking rules for the client's virtualnetwork include one or more of rules that encode virtual networkingsemantics and logic for networking primitives implemented in theclient's virtual network, rules that encode one or more networkingsecurity standards, or client-defined rules that encode the client'snetworking requirements.
 13. The method as recited in claim 8, furthercomprising receiving the rules for the client's virtual network from theclient, wherein the rules for the client's virtual network include rulesthat specify best practices for virtual networks as defined by theclient, and wherein the query is posed to verify that the client'svirtual network conforms to the best practices.
 14. The method asrecited in claim 8, wherein the query is posed to verify that a pathbetween a virtual machine in the client's virtual network and anothervirtual machine in the client's virtual network is open, to verify thata path between a virtual machine in the client's virtual network and oneor more entities external to the client's virtual network is open, or toverify that a virtual machine in the client's virtual network is notaccessible by entities that should not have access to the virtualmachine.
 15. The method as recited in claim 8, wherein providing resultsof the query resolution about the client's virtual network to the clientcomprises providing a textual representation of the results of the queryresolution to the client or providing a graphical representation of theresults of the query resolution to the client.
 16. The method as recitedin claim 8, further comprising receiving the query, obtaining thedescriptive information, and providing the results of the queryresolution according to an application programming interface to thevirtual network verification service.
 17. The method as recited in claim8, wherein the client's virtual network includes two peered virtualnetworks, wherein the query is posed to verify that a virtual machine ina first peered virtual network can communicate with another virtualmachine in a second peered virtual network via a peering connectionbetween the peered virtual networks over the provider network.
 18. Anon-transitory computer-readable storage medium storing programinstructions that when executed on one or more computers cause the oneor more computers to: receive one or more queries about a client'svirtual network on a provider network, wherein the queries are expressedas constraint problems, and wherein the provider network hosts aplurality of virtual networks for respective clients of a plurality ofclients; obtain rules for the client's virtual network, wherein one ormore different rules apply to different individual ones of the pluralityof virtual networks; encode the rules for the client's virtual networkaccording to a declarative logic programming language to generateencoded virtual networking rules for the client's virtual network;obtain descriptive information for the client's virtual network; encodethe descriptive information for the client's virtual network accordingto the declarative logic programming language to generate an encodeddescription of the client's virtual network; resolve the one or morequeries for the encoded description of the client's virtual networkaccording to the encoded virtual networking rules using a constraintsolver engine; and provide results of the resolution of the one or morequeries about the client's virtual network to the client.
 19. Thenon-transitory computer-readable storage medium as recited in claim 18,wherein the descriptive information is obtained from the client or fromone or more provider network services that maintain metadata describingvirtual networks.
 20. The non-transitory computer-readable storagemedium as recited in claim 18, wherein the descriptive informationcomprises one or more of information identifying instances of networkingprimitives that are implemented in the client's virtual network,descriptions of virtual machines in the client's virtual network,descriptions of relationships among the virtual machines in the client'svirtual network, or descriptions of interfaces to entities external tothe client's virtual network.
 21. The non-transitory computer-readablestorage medium as recited in claim 18, wherein the virtual networkingrules for the client's virtual network include one or more of rules thatencode virtual networking semantics and logic for networking primitivesimplemented in the client's virtual network, rules that encode one ormore networking security standards, or client-defined rules that encodethe client's networking requirements.